Visual programming system

ABSTRACT

Methods, systems, and system for generating code using visual blocks. A selection is made from a list of one or more programming blocks. One or more of the programming blocks are selected and used to display a visual programming block that corresponds to the selected one or more programming blocks. This visual programming block is then used to generate or produce output code.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of Provisional Application Ser. No.62/336,681, filed May 15, 2016, entitled “Visual Programming System,”which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

The present disclosure relates in general to techniques and devices fora visual programming system.

BACKGROUND

A computer-based visual programming system can be used to createapplications and scripts by arranging blocks representing activities andfunctions on a canvas. Individual blocks can represent certainfunctionality and can be connected with other blocks.

SUMMARY

Disclosed herein are aspects of a visual programming system andassociated methods.

According to an implementation, a visual programming system is provided.The system includes a processor and a memory. The memory includesinstructions executable by the processor to automatically generatedisplay code for rendering a first visual programming block andgeneration code for producing output code from a definition of aninterface to an application programming interface, render a plurality ofvisual programming blocks including the first visual programming blockon a visual programming canvas responsive to user input using at leastthe display code of the first visual programming block, and produceoutput code using at least the generation code of the first visualprogramming block.

These and other aspects of the present disclosure are disclosed in thefollowing detailed description of the embodiments, the appended claimsand the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

The description herein makes reference to the accompanying drawingswherein like reference numerals refer to like parts throughout theseveral views.

FIG. 1 is a block diagram of a distributed or cloud computing system.

FIG. 2 is a block diagram of an implementation of an internalconfiguration of a computing device, such as a computing device of thecomputing system as shown in FIG. 1.

FIG. 3 is a block diagram of an implementation of a high availabilityprocessing system.

FIG. 4A is a screen shot illustrating an implementation of a table thatincludes class definitions that define the interfaces of an API.

FIG. 4B is a screen shot illustrating an implementation of creating avisual program.

FIG. 5 is a screen shot illustrating the creation of a visual block.

FIG. 6 is a screen shot illustrating a new method entry form for theclass.

FIG. 7 is a screen shot illustrating the availability of a newly addedmethod.

FIG. 8 is a screen shot in which a method is added to an instantiationof a class.

FIGS. 9A & 9B are screen shots of a display of a visual programmingsystem and a compound block.

FIGS. 10 & 11 are screen shots illustrating a use of a suggestion block.

FIGS. 12A & 12B include an example code listing illustrating variousoperations.

FIG. 13 is a screen shot that shows an example of automatic rendering ofa record from a database.

FIG. 14 is a screen shot of a compound block and illustrating the scopesand nesting being taken care of.

FIGS. 15A & 15B include an example code listing of code generated fromnested blocks.

DETAILED DESCRIPTION

A visual programming system may be utilized for creating applications orscripts in which constituent components are displayed as visualprogramming blocks (also referred to as blocks) on a visual programmingcanvas (also referred to as a canvas) area of a screen.

Certain of the blocks may be automatically created from classdefinitions on the system. Compound blocks can be produced byaggregating individual blocks and provided parameters, and then thecompound blocks can, in turn, be combined with other compound blocks.Compound blocks can simplify the visual blocks displayed to a user whilemaintaining the functionality of the combined blocks.

Display code used to render the blocks and generation code used toproduce executable code from the block can be produced automatically foran interface (e.g., class or method) provided by application programminginterface (API), such as through a class definition, class reflection,static analysis of source code, run-time instrumentation of executionenvironments or other technique available for the determining structureand/or function of the API.

Once blocks and required parameters for the blocks are arranged on acanvas, executable code may be produced automatically using thegeneration code associated with the blocks. The executable code that isthereby generated (i.e. emitted) can take the form of a language (e.g.,JavaScript). The resultant JavaScript code can be stored in or used byplatform software that can be configured by or execute JavaScript code.

A user interface can be provided by platform software that permits auser to enter JavaScript code. Such a user interface can be enhanced byproviding the user the choice between providing the JavaScript codethrough a text editor, e.g., an IDE that provides color-coding and otherfunctionality for creating JavaScript code or to create the JavaScriptcode using a visual programming interface, such as using theimplementations described herein. The selection can be performed througha drop down, radio button, button, or other user interface elements.

Background Architecture

To describe some implementations in greater detail, reference is firstmade to examples of hardware structures and interconnections usable inimplementations of the present disclosure. FIG. 1 is a block diagram ofa distributed or cloud computing system 100. Use of the phrase “cloudcomputing system” herein is a proxy for any form of a distributedcomputing system, and this phrase is used simply for ease of reference.Cloud computing system 100 can have any number of customers, includingcustomer 110. Each customer 110 may have clients, such as clients 112.Each of clients 112 can be in the form of a computing system includingmultiple computing devices, or in the form of a single computing device,for example, a mobile phone, a tablet computer, a laptop computer, anotebook computer, a desktop computer, and the like. Customer 110 andclients 112 are examples only, and a cloud computing system may have adifferent number of customers or clients or may have a differentconfiguration of customers or clients. For example, there may behundreds or thousands of customers and each customer may have any numberof clients.

Cloud computing system 100 can include any number of datacenters,including datacenter 120. Each datacenter 120 may have servers, such asservers 122. Each datacenter 120 may represent a facility in a differentgeographic location where servers are located. Each of servers 122 canbe in the form of a computing system including multiple computingdevices, or in the form of a single computing device, for example, adesktop computer, a server computer and the like. The datacenter 120 andservers 122 are examples only, and a cloud computing system may have adifferent number of datacenters and servers or may have a differentconfiguration of datacenters and servers. For example, there may be tensof datacenters and each datacenter may have hundreds or any number ofservers.

Clients 112 and servers 122 may be configured to connect to network 130.The clients for a particular customer may connect to network 130 via acommon connection point 116 or different connection points (e.g. awireless connection point 118 and a wired connection point 119). Anycombination of common or different connections points may be present,and any combination of wired and wireless connection points may bepresent as well. Network 130 can be, for example, the Internet. Network130 can also be or include a local area network (LAN), wide area network(WAN), virtual private network (VPN), or any other means of transferringdata between any of clients 112 and servers 122. Network 130, datacenter120 and/or blocks not shown may include network hardware such asrouters, switches, load balancers and/or other network devices.

Other implementations of the cloud computing system 100 are alsopossible. For example, devices other than the clients and servers shownmay be included in system 100. In an implementation, one or moreadditional servers may operate as a cloud infrastructure control, fromwhich servers and/or clients of the cloud infrastructure are monitored,controlled and/or configured. For example, some or all of the techniquesdescribed herein may operate on said cloud infrastructure controlservers. Alternatively, or in addition, some or all of the techniquesdescribed herein may operate on servers such as servers 122.

FIG. 2 is a block diagram of an implementation of an internalconfiguration of a computing device 200, such as a client 112 or serverdevice 122 of the computing system 100 as shown in FIG. 1, including aninfrastructure control server of a computing system. As previouslydescribed, clients 112 or servers 122 may take the form of a computingsystem including multiple computing units, or in the form of a singlecomputing unit, for example, a mobile phone, a tablet computer, a laptopcomputer, a notebook computer, a desktop computer, a server computer andthe like.

The computing device 200 can include a number of components, asillustrated in FIG. 2. CPU (or processor) 202 can be a centralprocessing unit, such as a microprocessor, and can include single ormultiple processors, each having single or multiple processing cores.Alternatively, CPU 202 can include another type of device, or multipledevices, capable of manipulating or processing information now-existingor hereafter developed. When multiple processing devices are present,they may be interconnected in any manner, including hardwired ornetworked, including wirelessly networked. Thus, the operations of CPU202 can be distributed across multiple machines that can be coupleddirectly or across a local area or other network The CPU 202 can be ageneral-purpose processor or a special-purpose processor.

Random Access Memory (RAM) 204 can be any suitable non-permanent storagedevice that is used as memory. RAM 204 can include executableinstructions and data for access by CPU 202. RAM 204 typically comprisesone or more DRAM modules such as DDR

SDRAM. Alternatively, RAM 204 can include another type of device, ormultiple devices, capable of storing data for processing by CPU 202now-existing or hereafter developed. CPU 202 can access and manipulatedata in RAM 204 via bus 212. The CPU 202 may utilize a cache 220 as aform of localized fast memory for operating on data and instructions.

Storage 206 can be in the form of read only memory (ROM), a disk drive,a solid-state drive, flash memory, Phase-Change Memory (PCM), or anyform of non-volatile memory designed to maintain data for some durationof time, and preferably in the event of a power loss. Storage 206 caninclude executable instructions 206A and application files/data 206Balong with other data. The executable instructions 206A can include, forexample, an operating system and one or more application programs forloading in whole or part into RAM 204 (with RAM-based executableinstructions 204A and application files/data 204B) and to be executed byCPU 202. The executable instructions 206A may be organized intoprogrammable modules or algorithms, functional programs, codes, and codesegments designed to perform various functions described herein. Theoperating system can be, for example, a Microsoft Windows®, Mac OS X®,or Linux® operating system, or can be an operating system for a smalldevice, such as a smart phone or tablet device, or a large device, suchas a mainframe computer. The application program can include, forexample, a web browser, web server and/or database server. Applicationfiles 206B can, for example, include user files, database catalogs andconfiguration information. In an implementation, storage 206 includesinstructions to perform the discovery techniques described herein.Storage 206 may comprise one or multiple devices and may utilize one ormore types of storage, such as solid state or magnetic.

The computing device 200 can also include one or more input/outputdevices, such as a network communication unit 208 and interface 230 thatmay have a wired communication component or a wireless communicationscomponent 290, which can be coupled to CPU 202 via bus 212. The networkcommunication unit 208 can utilize any of a variety of standardizednetwork protocols, such as Ethernet, TCP/IP, or the like to effectcommunications between devices. The interface 230 can comprise one ormore transceiver(s) that utilize the Ethernet, power line communication(PLC), WiFi, infrared, GPRS/GSM, CDMA, etc.

A user interface 210 can include a display, positional input device(such as a mouse, touchpad, touchscreen, or the like), keyboard, orother forms of user input and output devices. The user interface 210 canbe coupled to the processor 202 via the bus 212. Other output devicesthat permit a user to program or otherwise use the client or server canbe provided in addition to or as an alternative to display 210. When theoutput device is or includes a display, the display can be implementedin various ways, including by a liquid crystal display (LCD) or acathode-ray tube (CRT) or light emitting diode (LED) display, such as anOLED display.

Other implementations of the internal configuration or architecture ofclients and servers 200 are also possible. For example, servers may omitdisplay 210. RAM 204 or storage 206 can be distributed across multiplemachines such as network-based memory or memory in multiple machinesperforming the operations of clients or servers. Although depicted hereas a single bus, bus 212 can be composed of multiple buses, that may beconnected to each other through various bridges, controllers, and/oradapters. Computing devices 200 may contain any number of sensors anddetectors that monitor the device 200 itself or the environment aroundthe device 200, or it may contain a location identification unit 260,such as a GPS or other type of location device. The computing device 200may also contain a power source 270, such as a battery, so that the unitcan operate in a self-contained manner. These may communicate with theCPU/processor 202 via the bus 212.

FIG. 3 is a block diagram of an implementation of a high availabilityprocessing system. The illustrated distributed computing system 300 canbe, for example, an implementation of datacenter 120 and network 130 ofFIG. 1. Broadly, the system 300 includes load balancers 304A, 304B andtwo datacenters 120A, 120B. The load balancers 304A, 304B are coupled toa telecommunications network graphically depicted by network 130. Loadbalancers 304A, 304B may also include reverse proxy load balancers.

The datacenter 120A includes a primary database 310A, and the datacenter120B includes a secondary database 310B. The datacenters 120A, 120Boperate in such a manner that the secondary database 310B can provide anexact or substantially exact mirror of the primary database 310A. A line320 is used to graphically emphasize the logical boundary betweendatacenters 120A and 120B. Depending upon the intended application, thedatabases 310A, 310B may be implemented using, for example, a relationaldatabase management system (RDBMS), an object database, an XML database,flat files, or the like.

Each datacenter can include two application nodes 122A1, 122A2, 122B1,122B2 (collectively or individually by way of example 122), although agreater or lesser number can be used depending on the implementation.The application nodes can be implemented using processing threads,virtual machine instantiations, or other computing features of thedatacenters that run programs on behalf of remotely sited clients, andexchange related data with such clients via the network 130. Inconnection with running these programs, occasions arise for theapplication nodes to store and retrieve data, with the databases 310Aand 310B filling this role. In an implementation, each of theapplication nodes connects to a single primary database, regardless ofwhether said database is located in the same datacenter as saidapplication node. For example, a primary database may be read/write anda secondary database may be configured to be read-only such that itmirrors changes from the primary database. Requests to the system 300may be routed to the application nodes in the datacenter of the primarydatabase first, followed by the other datacenter. In a failoversituation, the secondary database may become read/write with theformerly primary database switched to mirror the secondary database(which becomes the primary database). In this situation, eachapplication node can be reconfigured to point to the secondary database(now the primary database) as shown by the dashed lines.

As mentioned above, each datacenter 120A, 120B may have its own loadbalancer 304A, 304B. Each load balancer may be configured to directtraffic to respective servers and processing nodes located within itsdatacenter. In regard to proxy services, in one example the loadbalancers 304A, 304B are configured to provide a singleInternet-delivered service to remote clients via the network 130, wherethis service is actually provided by a server farm composed of thecomputerized servers of the datacenters 120A, 120B. The components 304A,304B also coordinate requests from remote clients to the datacenters120A, 120B, simplifying client access by masking the internalconfiguration of the datacenters. The components 304A, 304B may servethese functions by directing clients to processing nodes as configureddirectly or via DNS. Load balancer 304A, 304B can be configured forsticky sessions. With sticky sessions, the load balancer can attempt toforward all requests from a client to the same application node 122A1,122A2. Different sticky session implementations are available. Forexample, in an implementation, a load balancer can be configured todirect all requests associated with a particular session to a sameapplication node, so long as that node is available.

In regard to load balancing, the components 304A, 304B can be configuredto direct traffic to the secondary datacenter in the event the primarydatacenter 120A experiences one of many enumerated conditions predefinedas failure. The load balancing functionality of the components 304A,304B can be provided as separate components or as a single component.

The features and implementations associated with systems and methodsdisclosed herein can be included, in whole or in part, as part of one ormore graphical display regions for outputting data to display for auser. In an implementation, a graphical display region can comprise partof a software graphical user interface constituting data that reflectsinformation ultimately destined for display on a hardware device. Forexample, the data can contain rendering instructions for boundedgraphical display regions, such as windows, or pixel informationrepresentative of controls, such as buttons and drop-down menus. Therendering instructions can be in the form of HTML, SGML, JavaScript,Jelly, AngularJS, or other text or binary instructions for generating agraphical user interface on a display that can be used to generate pixelinformation. A structured data output of one device can be provided toan input of the hardware display so that the elements provided on thehardware display screen represent the underlying structure of the outputdata.

Visual Programming System Architecture

A visual programming system is a tool for creating applications orscripts using graphical blocks. A requirement that blocks must bemanually created for use with a visual programming system can reduce theeffectiveness of these tools for larger scale development, such as in anenterprise or platform environment.

An implementation of a visual programming system can provide automatedfeatures that can improve the effectiveness of visual programming forgenerating applications and scripts. These automated features caninclude automatically creating visual blocks from class definitions andautomatically generating code for execution from the blocks. Thecreation can include automatically producing display code to renderblocks appropriate for class and function definitions of an API andautomatically producing generation code to generate output code afterthe blocks are combined and then executed. Although implementationsherein may describe the generation of JavaScript, in alternativeimplementations, code can be output in any programming language with aknown grammar, and the discussion of JavaScript below can be appliedequally to other languages.

FIG. 4A is a screen shot 450 illustrating an implementation of a tablethat includes class definitions that define the interfaces of an API.Display code to render blocks for this API and generation code to usethis API may be produced based on this table and other data associatedwith the functions listed therein. For example, the definition of“getUniqueValue( )” with a return value of “DTBlock_FieldTextInput” canprompt the system to generate code to render a block without any inputsand with an output based on the return value.

FIG. 4B is a screen shot illustrating an implementation of creating avisual program. In the initial display 400, a block element 410 isprovided that visually depicts the start of a program. The blocksgenerated for APIs such as described above with respect to FIG. 4A canbe used by dragging the block into block element 410 in response to userinput, such as by using a pointing or touchscreen device.

FIG. 5 is a screen shot illustrating the creation of a visual block 510to instantiate or refer to a GlideRecord 520 class (e.g., a databaseaccess class), which has methods that may have return types, and theymay or may not be static. The GlideRecord visual block allows theprogrammer access to the constituent components of the class, such as atableName 530 that can point to a table (e.g., an incident table 540).This block 510 can be generated/rendered automatically without requiringthe writing of additional code.

FIG. 6 is a screen shot illustrating a new method entry form for aclass. The new method, “foo,” is provided in a name field 610 and labelfield 620, and a return type of integer is specified in a return typefield 630. The function scope is identified as Global in the applicationfield 640, and it is identified as being a part of the class GlideRecord650.

FIG. 7 is a screen shot illustrating the availability of a newly addedmethod. As can be seen, the method foo 710 is now available forselection. When foo is selected, the system knows that foo returns aninteger, and thus presents a display block 720 that requests an integerreturn value. The user, in this example, specifies an integer returnvalue of “3”. The class definition assumes that the underlying classincludes the defined method. In this example, the class GlideRecord mustactually implement the method “foo” for the block generated from thisclass definition to output code that will result in the execution of thefoo method.

While class definitions can be used to automatically generate theblocks, the class definitions themselves can be automatically generatedusing a number of different methods other than a manual classdefinition, such as by using Java Reflection. In such an implementation,to the extent that application program interface (API) points areexposed in JavaScript, they can be located and inserted automaticallyfor the APIs. In an alternative implementation, a static analysis of APIcode can be performed to generate a set of stacks for which APIs areavailable. Also, an analysis can be done at run-time by actuallyexamining how the JavaScript is behaving while it is being executed bythe JavaScript runtime engine. In an implementation, JavaScriptannotations may be used to determine which interfaces of an API shouldbe exposed as blocks in the visual programming system.

Advantageously, the use of visual programming and automatic generationof block generation code can mitigate against the introduction ofprogramming errors, given that, according to an implementation, theremay be only one set of code that produces display code and generationcode. Thus, the resulting output code (e.g., JavaScript) can be producedin a common way across all blocks, even though the generation code maybe customized for each block based on that block's associated interfaceto an API.

FIG. 8 is a screen shot in which an addQuery method is added to aninstantiation of class GlideRecord. The addQuery method may be selected810 from a list of methods, and an incident state 820 may be added.

FIG. 9A, which is a screen shot of an overall display of animplementation of a visual programming system, illustrates how, as thevisual block element 910 builds on the display 900, it can becomevisually complex. In a top-right region of the display, a correspondingprototype compound block 920 that abstracts out the visual block elementto remove certain blocks, inputs and outputs, while preserving aspects(e.g., unfilled inputs and outputs to the visual block is displayed). Ina bottom-right region of the display, output code 930 generated usingthe generation code of the constituent blocks disposed within visualblock element 910 is shown. The visual programming system can beconfigured to automatically update prototype compound block 920 andoutput code 930 as the user updates the configuration of and blockswithin visual block element 910 by updating aspects of the blocks (e.g.,changing the inputs to or outputs of blocks within visual block element910, adding blocks, removing blocks, or a combination thereof).

The prototype compound block 920 can be saved, and the display code andgeneration code of the resulting compound block can be automaticallyproduced without having to write any further code.

As shown in FIG. 9B which is a similar screen shot to FIG. 9A, acollection of blocks can be reduced to a simpler block while preservingits behavior. In the example shown in FIG. 9B, the compound blockincludes: a) the query field is “bound” to the table name so that onlyfields from the table are displayed (but this table is not defined untilgeneration time); b) the types from the original blocks are preserved inthe compound block; and c) the block becomes its own scoped entity. Thisis a way of refactoring the blocks into a compound block for subsequentuse.

FIG. 10 is a screen shot illustrating a use of a suggestion block. Thedisplay 1000 shows how a selection of the do element 1010 causes anelement, such as a drop-down list block 1020, to provide suggestions forthe types of elements that can be used at a particular location. Forexample, as shown, possible selectable elements include lists 1030,collections 1040, and controls 1050. In an implementation, suggestionblocks can be driven by typing script into the canvas in addition to thegraphical dragging and dropping of visual elements.

FIG. 11 is a screen shot illustrating a use of a suggestion block. Thedisplay 1100 shows how a selection of the while condition, which mustevaluate to a Boolean expression, only provides, in a drop-down listblock 1120, only options that ultimately evaluate to a Boolean value.Although a drop-down list box is shown as a selection mechanism, one ofordinary skill in the art will appreciate that any form of selectionmechanism that presents selectable options to a user can be used. Inorder to provide meaningful options with such a selection mechanism, inan implementation, variables may be strongly typed. This allows theselection mechanism to determine suitable selection options that areproperly of the same type of the selected entity.

When a function or construct representation has parameters, in animplementation, in order to assist the user in getting at the arguments,the user can drag the parameters from the representation so that theycan be filled in. For example, a user can drag an indicator of the loopvariable to create a do block.

To generate a compound block, the system can take the code fromconstituent blocks and can automatically generate the compound blockcode. In an implementation, the compound block is first traversed todetermine what elements are missing from it. Making this determinationallows the system to allow the user to plug in the missing elements. Thecompound block is generated by putting together a number of blocks, andthen determining what the inputs are and what the outputs are to thatgroup of blocks to create the compound block.

If the compound block is assigned a return value, that can become itsoutput. If there is no return value, then the compound block may nothave an output. Any time, however, that a hole is left in a constituentblock, a hole is created for the compound block that will require a userto fill it in. The system also allows renaming of the compound block,since the original name might not be meaningful to an external user whocannot see the internal details of the compound block. Thus, in additionto the automatic generation of code based on class definitions to createAPI points, the system, according to an implementation, can perform theautomatic generation of code for compound blocks.

As previously described, there can be two stages for creating theblock-producing display code and producing generation code. The firststage of producing display code permits the rendering of the physicalrepresentation of the block that can be placed on a canvas and thatinforms a user where the holes are that require something else to beplugged in. If there is a type to those holes, assistance can beprovided so that the wrong type of data is not used in a particularhole.

The second stage for creating the block involves producing generationcode (e.g., how the JavaScript code to be run is generated from theblock). For both API blocks and compound blocks, it is not known whatthe output code will look like until the user plugs everything into theholes of a particular block, at this stage, generation code must beemitted/generated that can recognize other blocks that are plugged intothe current block and appropriately generate output code for any suchvalid combination of blocks.

In one implementation, a basic block may be generated that can exposethe entire functionality of a given API and can permit the creation ofsubsequent compound blocks. The subsequently created compound blocks maybe utilized to expose certain desirable inputs or outputs of the basicblock for particular use cases. For example, a compound block can becreated from a glide record (database access) block that is configuredto query for all records matching criteria x and y from a predefinedtable (e.g. an incident table). Such a compound block can greatlysimplify the use of the visual programming system by replacing a largenumber of possible inputs and outputs and reducing those inputs andoutputs to two—criteria x and y.

When compound blocks are created, the scoping of variables can beaddressed to avoid collisions between variables within and outside ofthe compound block. Compound blocks can create new scope because theinside of the compound block is not visible, and the inside of acompound block can be quite complex.

When multiple blocks are combined, a mechanism to generate unique namescan permit their combination without having variable names collide. Thatis, since the routine that produces code from the blocks is outputtingcode to a language, such as JavaScript, this code production process cancreate conflicts with variables being defined within the compound blockthat could collide with names that were already in the compound blocks.Thus, the function calls can be created in a way such that the names andname spaces do not collide. This can be of particular use when compoundblocks are placed inside of other compound blocks. The compound blockscan have their own scope internally, so as to avoid creating scopeproblems externally.

In an implementation, a two-pass system may be used where initially thefirst pass generator produces source code, and then this source code isparsed to resolve variable conflicts and scoping issues (i.e., patchingup the variables) to produce final source code. This final source codecan then be compiled or interpreted to have executable code. However, inanother implementation, the scoping can be performed without going inand patching up the variables. By way of example, a user writes codedefining variables A through D, and the user wants to use a compoundblock. The compound block opens a record, scans it, and then allows theuser to perform functions like ask “what is the value of name”, “what isthe value of an employee identification number”, etc., on the record.The visualization of the compound block has a hole for a statementinput, and floating above it are the variables that are available forthe user to use in the record. The user defines the variables A throughD above the compound block context, but these variables need to be inputinto the compound block. But the compound block also has its ownvariables for the record that are found within the scope of the compoundblock. By ensuring that the variable names do not collide, it ispossible to perform a stacking of scopes on top of each other.

FIGS. 12A & B include an example code listing 1200. Block code may begenerated as the compound blocks can be built and stored when the blockis stored. A first component of the code 1210 can perform blockvisualization and type checking. The “this” element in the init functionrepresents the smaller block that is being generated. A second componentof the code 1220 provides the scoped variable rules—these rulesrepresent pre-generated relationships that are to be later determined.By way of example, if the user selects a query and then fills in a tablename, only fields from that table should be shown. This variable isbound to the table name. A third component of the code 1230 providespre-generated code to be completed when the compound block is used. Thisis parsed when emitting the final code. In the compound block, there arevalues that are missing, so code must be generated that allows values tobe plugged in when the users actually fill in the values (implemented inthe example shown as a JSON list). A fourth component of the code 1240provides dependent field mappings. The dependent field mappings relateto the scoped variable rules that allow the system to determine what isin scope at any of the statement lines. In the illustration shown, theglide record is bound to the statement input below, meaning that thestatement input can access that particular (instance of a) GlideRecord.

FIG. 13 is a screen shot 1300 that shows an example of automaticrendering of a record from the database. FIG. 14 is a screen shot 1400of a nested compound block. FIGS. 15A & B include an example codelisting 1500 of code generated from nested blocks that can, among otherfeatures, preserve scope renaming and prevent name collisions fromcustomer-created blocks. The functions calls 1510 illustrate the nestingof the blocks.

The avoiding of variable name collisions when combining blocks may beachieved by automatically renaming variables so that they are globallyunique. Thus, when a first compound block is dropped into a secondcompound block, there are two different workspaces, and the internalsare changed to prevent name conflicts.

In a first way to avoid collisions, a global list of all variables canbe maintained. By way of example, a scoped variable, like a gliderecord, can require each query to be handled in a particular way. If auser adds many of these queries to a block, that glide record should berenamed for each of the queries. A new variable name is created for eachinstance (e.g., glide record A, glide record B). There is a mapping thatindicates which (and how) each scoped variable is renamed. The systemcan keep track of the order that the scoped variable is declared at eachof the statement inputs, so it can access its scoped variables anddetermine their original names. Thus, the system can determine whichnames need to be injected so as to keep variables from colliding indifferent scopes. In a second way to avoid collisions, self-callingfunctions may be utilized (as in the nested code example of FIGS. 15A &B).

All or a portion of aspects of the invention described herein can beimplemented using a general-purpose computer/processor with a computerprogram that, when executed, carries out any of the respectivetechniques, algorithms and/or instructions described herein. Inaddition, or alternatively, for example, a special-purposecomputer/processor can be utilized which can contain specializedhardware for carrying out any of the techniques, algorithms, orinstructions described herein.

The implementations of computing devices as described herein (and thealgorithms, methods, instructions, etc., stored thereon and/or executedthereby) can be realized in hardware, software, or any combinationthereof. The hardware can include, for example, computers, intellectualproperty (IP) cores, application-specific integrated circuits (ASICs),programmable logic arrays, optical processors, programmable logiccontrollers, microcode, microcontrollers, servers, microprocessors,digital signal processors or any other suitable circuit. In the claims,the term “processor” should be understood as encompassing any of theforegoing hardware, either singly or in combination.

For example, one or more computing devices can include an ASIC orprogrammable logic array such as a field-programmable gate array (FPGA)configured as a special-purpose processor to perform one or more of theoperations or operations described or claimed herein. An example FPGAcan include a collection of logic blocks and random access memory (RAM)blocks that can be individually configured and/or configurablyinterconnected in order to cause the FPGA to perform certain functions.Certain FPGA's may contain other general or special-purpose blocks aswell. An example FPGA can be programmed based on a hardware definitionlanguage (HDL) design, such as VHSIC Hardware Description Language orVerilog.

The embodiments herein may be described in terms of functional blockcomponents and various processing operations. Such functional blocks maybe realized by any number of hardware and/or software components thatperform the specified functions. For example, the described embodimentsmay employ various integrated circuit components (e.g., memory elements,processing elements, logic elements, look-up tables, and the like) whichmay carry out a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, where the elementsof the described embodiments are implemented using software programmingor software elements the invention may be implemented with anyprogramming or scripting language such as C, C++, Java, assembler, orthe like, with the various algorithms being implemented with anycombination of data structures, objects, processes, routines or otherprogramming elements. Functional aspects may be implemented inalgorithms that execute on one or more processors. Furthermore, theembodiments of the invention could employ any number of conventionaltechniques for electronics configuration, signal processing and/orcontrol, data processing and the like. The words “mechanism” and“element” are used broadly and are not limited to mechanical or physicalembodiments, but can include software routines in conjunction withprocessors, etc.

Implementations or portions of implementations of the above disclosurecan take the form of a computer program product accessible from, forexample, a computer-usable or computer-readable medium. Acomputer-usable or computer-readable medium can be any device that can,for example, tangibly contain, store, communicate, or transport aprogram or data structure for use by or in connection with anyprocessor. The medium can be, for example, an electronic, magnetic,optical, electromagnetic, or a semiconductor device. Other suitablemediums are also available. Such computer-usable or computer-readablemedia can be referred to as non-transitory memory or media, and mayinclude RAM or other volatile memory or storage devices that may changeover time. A memory of an apparatus described herein, unless otherwisespecified, does not have to be physically contained by the apparatus,but is one that can be accessed remotely by the apparatus, and does nothave to be contiguous with other memory that might be physicallycontained by the apparatus.

The word “example” is used herein to mean serving as an example,instance, or illustration. Any aspect or design described herein as“example” is not necessarily to be construed as preferred oradvantageous over other aspects or designs. Rather, use of the word“example” is intended to present concepts in a concrete fashion. As usedin this application, the term “or” is intended to mean an inclusive “or”rather than an exclusive “or”. That is, unless specified otherwise, orclear from context, “X includes A or B” is intended to mean any of thenatural inclusive permutations. In other words, if X includes A; Xincludes B; or X includes both A and B, then “X includes A or B” issatisfied under any of the foregoing instances. In addition, thearticles “a” and “an” as used in this application and the appendedclaims should generally be construed to mean “one or more” unlessspecified otherwise or clear from context to be directed to a singularform. Moreover, use of the term “an implementation” or “oneimplementation” throughout is not intended to mean the same embodimentor implementation unless described as such.

The particular implementations shown and described herein areillustrative examples of the invention and are not intended to otherwiselimit the scope of the invention in any way. For the sake of brevity,conventional electronics, control systems, software development andother functional aspects of the systems (and components of theindividual operating components of the systems) may not be described indetail. Furthermore, the connecting lines, or connectors shown in thevarious figures presented are intended to represent exemplary functionalrelationships and/or physical or logical couplings between the variouselements. Many alternative or additional functional relationships,physical connections or logical connections may be present in apractical device. Moreover, no item or component is essential to thepractice of the invention unless the element is specifically describedas “essential” or “critical”.

The use of “including,” “comprising,” or “having” and variations thereofherein is meant to encompass the items listed thereafter and equivalentsthereof as well as additional items. Unless specified or limitedotherwise, the terms “mounted,” “connected,” “supported,” and “coupled”and variations thereof are used broadly and encompass both direct andindirect mountings, connections, supports, and couplings. Further,“connected” and “coupled” are not restricted to physical or mechanicalconnections or couplings.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the invention (especially in the context of thefollowing claims) should be construed to cover both the singular and theplural. Furthermore, recitation of ranges of values herein are merelyintended to serve as a shorthand method of referring individually toeach separate value falling within the range, unless otherwise indicatedherein, and each separate value is incorporated into the specificationas if it were individually recited herein. Finally, the operations ofall methods described herein are performable in any suitable orderunless otherwise indicated herein or otherwise clearly contradicted bycontext. The use of any and all examples, or exemplary language (e.g.,“such as”) provided herein, is intended merely to better illuminate theinvention and does not pose a limitation on the scope of the inventionunless otherwise claimed.

All references, including publications, patent applications, andpatents, cited herein are hereby incorporated by reference to the sameextent as if each reference were individually and specifically indicatedas incorporated by reference and were set forth in its entirety herein.

The above-described embodiments have been described in order to alloweasy understanding of the present invention and do not limit the presentinvention. To the contrary, the invention is intended to cover variousmodifications and equivalent arrangements included within the scope ofthe appended claims, which scope is to be accorded the broadestinterpretation so as to encompass all such modifications and equivalentstructure as is permitted under the law.

What is claimed is:
 1. A system comprising: one or more processors; andmemory having instructions stored thereon that, when executed by the oneor more processors, are configured to cause the one or more processorsto: cause a display to display a plurality of programming blocks;receive a selection of a programming block of the plurality ofprogramming blocks; responsive to receiving the selection, cause thedisplay to display a visual programming block corresponding to theprogramming block; and produce output code based at least in part on thevisual programming block.
 2. The system of claim 1, wherein theselection comprises a drag-and-drop of the programming block into thevisual programming block.
 3. The system of claim 1, wherein theselection comprises a textual entry of a name of the programming blockto incorporate the programming block into the visual programming block.4. The system of claim 1, wherein the instructions are configured tocause the one or more processors to cause the display to display theplurality of programming blocks as a list of available functions,application programming interfaces, or previously generated visualprogramming blocks, or a combination thereof.
 5. The system of claim 1,wherein producing the output code comprises: generating a preliminarysource code; parsing the preliminary source code; and resolving variableconflicts using the parsed preliminary source code to produce the outputcode based at least in part on the resolved variable conflicts.
 6. Thesystem of claim 1, wherein the instructions are configured to cause theone or more processors to cause the display to display the visualprogramming block with constituent components of the visual programmingblock.
 7. The system of claim 6, wherein the constituent componentscomprise a table.
 8. The system of claim 6, wherein the constituentcomponents comprise return values of the visual programming block. 9.The system of claim 1, wherein the plurality of programming blocksincludes a previously generated visual programming block, and whereinthe visual programming block comprises a compound block formed at leastpartially from the previously generated visual programming block. 10.The system of claim 1, wherein the visual programming block comprises acompound block incorporating the plurality of programming blocks, andwherein the instructions are configured to cause the one or moreprocessors to scope variables of the compound block.
 11. The system ofclaim 10, wherein scoping the variables comprises renaming all variablesin each constituent block to be globally unique.
 12. The system of claim10, wherein scoping the variables comprises: creating a global list ofvariables in the compound block; and when redundant variables are on theglobal list, append a textual modifier to distinguish the redundantvariables from each other.
 13. The system of claim 1, wherein theinstructions are configured to cause the one or more processors togenerate the visual programming block from a class definition.
 14. Thesystem of claim 1, wherein the instructions are configured to cause theone or more processors to generate the visual programming block from aplurality of methods of an object-oriented programming language.
 15. Thesystem of claim 1, wherein causing the display of the visual programmingblock comprises generating display code from the visual programmingblock to display parameters input into or returned out of the visualprogramming block.
 16. Non-transitory, computer-readable, and tangiblemedium having instructions stored thereon that, when executed by aprocessor, are configured to cause the processor to: cause a display todisplay a plurality of programming blocks each corresponding toavailable functionality; receive a selection of two programming blocksof the plurality of programming blocks; generate display code to causethe display to display a visual programming block corresponding to thetwo programming blocks; responsive to receiving the selection of the twoprogramming blocks, cause the display to display the visual programmingblock based on the display code; and generate final output code based atleast in part on the visual programming block.
 17. The non-transitory,computer-readable, and tangible medium of claim 16, wherein at least oneof the two programming blocks includes a previously generated visualprogramming block.
 18. The non-transitory, computer-readable, andtangible medium of claim 16, wherein the instructions are configured tocause the processor to: determine whether a hole exists in constituentblocks of the visual programming block; and responsive to determiningthat the hole exists, request an entry in an input device to fill thehole, wherein generating the final output code is based at least in parton the filled hole.
 19. The non-transitory, computer-readable, andtangible medium of claim 18, wherein determining whether the hole existscomprises traversing the constituent blocks to determine whether anyinputs or outputs from the constituent blocks are not used in the visualprogramming block.
 20. The non-transitory, computer-readable, andtangible medium of claim 16, wherein the instructions are configured tocause the processor to cause the display to display assistance to ensurethat data type mismatches do not exist in the visual programming block,wherein data type mismatches comprise an output of a first block ofconstituent blocks of the visual programming block to be input to asecond block of the constituent blocks when the output data type of thefirst block differs in type from an expected input data type into thesecond block.